Until now, our server framework integrations used to only report status codes in the 5xx range to Sentry. The reasoning was that the client should report client side errors.

However, not everyone has the client instrumented or wants to have it instrumented, and they might want to have the client range 4xx reported to Sentry by the server integration.

Docs PR: getsentry/sentry-docs#10282

Closes #2825

Failed request status codes

In this PR, we're adding a new option to Starlette and FastAPI called failed_request_status_codes (naming based on develop docs) to make it possible to configure which status codes should be reported to Sentry. If no failed_request_status_codes are provided, we default to the 5xx range.

failed_request_status_codes is a list of status code ranges, where a status code range is one of:

• single number
• a sequence with a __contains__ method (so that we can check whether a code is in the sequence with in)

The following are examples of valid failed_request_status_codes:

• [500]
• [403, range(500, 599)]
• [{500, 501, 502, 503}]

Follow up

• do something analogous for non-http integrations as well, for example GraphQL Integrations: Ariadne - handled tag is always False  #2904 -- could be a function akin to before_send which gets the exception and can decide on its own whether to report it
• more integrations, if applicable (we don't raise events based on HTTP status everywhere): Add failed_request_status_codes for more web frameworks #3134

General Notes

Thank you for contributing to sentry-python!

Please add tests to validate your changes, and lint your code using tox -e linters.

Running the test suite on your PR might require maintainer approval. Some tests (AWS Lambda) additionally require a maintainer to add a special label to run and will fail if the label is not present.

For maintainers

Sensitive test suites require maintainer review to ensure that tests do not compromise our secrets. This review must be repeated after any code revisions.

Before running sensitive test suites, please carefully check the PR. Then, apply the Trigger: tests using secrets label. The label will be removed after any code changes to enforce our policy requiring maintainers to review all code revisions before running sensitive tests.